home *** CD-ROM | disk | FTP | other *** search
/ Experimental BBS Explossion 3 / Experimental BBS Explossion III.iso / gus / digestv3.zip / V3N29M.TXT < prev    next >
Text File  |  1993-12-30  |  7KB  |  155 lines
  1. Apparently-To: john.smith@gravis.com
  2.  
  3.  
  4. GUS Musician's Digest       Thu, 30 Dec 93  3:28         Volume 3: Issue  29  
  5.  
  6. Today's Topics:
  7.                             Forte response
  8.                              unsubscribe
  9.                              XMID problem
  10.  
  11. Standard Info:
  12.     - Meta-info about the GUS can be found at the end of the Digest.
  13.     - Before you ask a question, please READ THE FAQ.
  14.  
  15. ----------------------------------------------------------------------
  16.  
  17. Date: Wed, 29 Dec 93 18:30:53 CST
  18. From: chuth@lonestar.utsa.edu (Cornel H. Huth)
  19. Subject: Re: Forte response
  20.  
  21. > > Just who are they trying to scare? Developers like me? Take a hike, bozos.
  22.  
  23. > First of all, CONSTRUCTIVE criticism is always welcome. Comments like this
  24. > last sentence are neither appreciated or called for.
  25.  
  26. That's one line compared to several paragraphs. Heh. If you don't like it:
  27. tough tities.
  28.  
  29. > Its still wrong because nobody brought the error to our attention. It
  30. > is indeed flipped. The low nibble is the start fraction and the high
  31. > nibble is the end fraction. We'll fix it also.
  32.  
  33. And you don't know already? It's been like that since the beta SDK and that
  34. was a July 1992 publication. Do you even read/use your own SDK? I can't
  35. imagine so because it is, for practical purposes, useless. And even your
  36. above explanation is ambiguous. It's loop start fraction, not start fraction.
  37. Two separate things.
  38.  
  39. > > should not have left Canada as is. I would feel very uneasy about using
  40. > > any of the code in this SDK, to say the least. Actually, since I write
  41.  
  42. > As far as I know, there are no bugs in the SDK code. We use it for a lot
  43. > of stuff and don't have any problems. I would encourage people to use
  44.  
  45. Famous last words. The previous SDK (2.01) was competely useless to anyone
  46. not able to fix the numerous problems themselves. And this time 'round, not
  47. a single mention of any changes/fixes. No wonder you have all those bugs in
  48. there for so long -- no tracking.
  49.  
  50. > the code as is for as much as possible. I have spent countless hours
  51. > working with people who subscribe to the 'not invented here' syndrome.
  52. > 90% of those people could have used this code with absolutely no
  53.  
  54. I sense a bit of hostility here. I "invented" my own because yours was
  55. so, need I say it again, utterly and completely useless.
  56.  
  57. > if you can't use the code directly, it is usually simple enough for
  58. > somebody to extract the pieces they need for their application.
  59.  
  60. That's about all it is, a collection of pieces. Nothing holds it together.
  61.  
  62. > Obviously, the SDK does not have a lot of in-depth info on the patches
  63. > or how to implement them. That is not its primary focus. Most developers
  64.  
  65. Obviously? Is that some sort of reason why it's not there? Not it's primary
  66. focus? There's no focus. How's that? If you're going to do an SDK, why not
  67. do a complete one? This 2.10 thing is something I'd expect from a rag-tag
  68. organization.
  69.  
  70. > do not want to deal with that high of a level. If they do, MOST use
  71. > Ultramid, so they don't need to worry about the implementation details.
  72.  
  73. Who cares what most do? And I'd hardly call documenting the patches (and
  74. without numerous errors) "that high of a level". I'd call it a basic
  75. requirement. And, to follow your arguement, if "most" programmed for SBOS,
  76. would that mean there'd be an SDK on how to use SBOS and nothing else? (Silly
  77. premise, silly arguement). And if most are using ultramid.exe, a rather large
  78. and cumbersome TSR, then they are doing so because that's the only choice they
  79. have. It also means that they pretty much have to write to ultramidi and then
  80. write completely separate code to access other cards. Or are you under the
  81. impression that GUS developers only write for the GUS? Not likely, unless one
  82. likes to dismiss 99% of other users (the GUS having about 1% of the soundcard
  83. market, tops).
  84.  
  85. > We will probably add more info/examples in future SDKs.
  86.  
  87. What have you been doing the past year and a half? Maybe you people have
  88. been sitting on your high-horse too long. Come done in the trenches were
  89. your real support will be drawn from. When, in this next year, there are
  90. no new GUS-supported products out, relatively speaking, it's your job that
  91. goes out the window, not mine. Then again, being Forte, you can always go
  92. on to something else and just dump the GUS.
  93.  
  94. > I would like to thank Cornel for reviewing the doc. We NEED the feedback
  95. > so that we can make fixes/additions to the SDK to make it more useable.
  96. > If anybody else has any comments etc, please let us know. I can't promise
  97. > that we will be able to provide everything you want, but we'll try.
  98.  
  99. Just who is responsible for this? I'd like to see some names and e-mail
  100. addresses instead of this occasional, once-every-other-month pop-in by
  101.  
  102. > Forte Tech Support.
  103.  
  104. (ha!)
  105.  
  106. ------------------------------
  107.  
  108. Date: Wed, 29 Dec 1993 20:46:46 +0800 (CST)
  109. From: cp79071@csie.nctu.edu.tw (Until the End of the world...)
  110. Subject: unsubscribe
  111.  
  112.  
  113.  
  114. ------------------------------
  115.  
  116. Date: Thu, 30 Dec 1993 00:52:58 -0500
  117. From: jgamache@AIX1.si.usherb.ca (Jerry Gamache)
  118. Subject: XMID problem
  119.  
  120. Just found an XMID file, don't know what to do with it, could you
  121. please tell me where I can find one of the following options...
  122.  
  123. a: Program that imports them
  124. b: Program that converts them
  125. c: Files that tell me how they work
  126. d: Files that tell me how to find the program changes
  127.                         
  128.             En vous remerciant d'avance...
  129.  
  130.                         Jerry
  131.                         jgamache@aix1.si.usherb.ca
  132.  
  133. ------------------------------
  134.  
  135. End of GUS Musician's Digest V3 #29
  136. ***********************************
  137.  
  138. To post to tomorrow's digest:                        <gus-music@dsd.es.com>
  139. To (un)subscribe or get help:                <gus-music-request@dsd.es.com>
  140. To contact a human (last resort):              <gus-music-owner@dsd.es.com>
  141.  
  142. FTP sites:           archive.epas.utoronto.ca              /pub/pc/ultrasound
  143.                      wuarchive.wustl.edu            /systems/ibmpc/ultrasound
  144.                      archive.orst.edu                    /pub/packages/gravis
  145.                      theoris.rz.uni-konstanz.de                /pub/sound/gus
  146.                      nctuccca.edu.tw                           /PC/ultrasound
  147. FTP mail server:     mail-server@nike.rz.uni-konstanz.de
  148.  
  149. Hints:
  150.       - Get the FAQ from the FTP sites or the request server.
  151.       - Mail to <gus-music-request@dsd.es.com> for info about other
  152.     GUS related mailing lists (general use, programmers, etc.).
  153.  
  154.  
  155.